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REMARKS 

This is in response to the Office Action mailed May 15, 2006. Reconsideration of this 
application is respectfully requested in view of this amendment. 

STATUS OF CLAIMS 

Claims 1 -27 are pending. 

Claims 1-4, 7-14, 18-23, and 27 stand rejected under 35 U.S.C. § 102(e) as being 
anticipated by U.S. 6,708,202 (Shuman). 

Claims 5, 15, and 25 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. 6,708,202 (Shuman) as applied to claims 1, 10, and 23 above, and further in view of 
U.S. 2002/0116505 (Higgins). 

Claims 6 and 16 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. 6,708,202 (Shuman) and U.S. 2002/0116505 (Higgins) as applied to claims 1, 5, 10, and 15 
above, and further in view of U.S. 6,828,989 (Cortright). 

Claim 17 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. 6,708,202 (Shuman) as applied to claim 14 above, and further in view of U.S. 6,990,513 
(Belfiore). 

Claim 26 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. 6,708,202 (Shuman) as applied to claim 23 above, and further in view of U.S. 6,347,307 
(Sandhu). 
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OVERVIEW OF CLAIMED INVENTION 
The present invention provides for a system and method to automatically retrieve and 
render information regarding a source of incoming communications, said method comprising a 
plurality of steps, one or more of said steps implemented locally or remotely, wherein the method 
comprises: (a) receiving an incoming communication from a source intended for one or more 
recipients, said incoming communications comprising a plurality of communication types 
selected from the group: e-mail, telephone, fax, IM, collaborative message, or combination 
thereof; (b) detecting identity of said source; (c) retrieving from a database, data regarding said 
detected source, and extracting data comprising any of, or a combination of, the following 
information: to-do entries, future and past event entries, journal entries, and profile information; 
(d) summarizing said extracted data; (e) notifying said one or more recipients of said incoming 
communication, and (f) rendering said data in one or more electronic devices associated with said 
one or more recipients of said incoming communication. The present invention also provides an 
article of manufacture comprising a computer usable medium having computer readable program 
code embodied therein implementing the steps of this method. 

The present invention also provides for a system for automatic retrieval and rendering 
of information related to one or more sources, wherein the system comprises: (a) one or more 
databases storing information related to one or more sources, said databases accessible over one 
or more networks; (b) one or more device agents detecting incoming communications from said 
sources, said incoming communications comprising a plurality of communication types selected 
from the group: e-mail, telephone, fax, IM, collaborative message, or combination thereof, said 
device agents further extracting identity of said sources; (c) a retrieval manager operatively 
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linked to said agents initiating retrieval of data, regarding said identified sources, from said 
databases, and (d) a presenter operatively linked to said retrieval manager rendering said 
retrieved data in one or more electronic devices. 

The present invention also provides for a method for facilitating business transactions, 
based on information retrieved over the World Wide Web, wherein the method comprises: 
receiving an incoming communication from a business, said incoming communication 
comprising a plurality of communication types selected from the group: e-mail, telephone, fax, 
IM, collaborative message, or combination thereof; detecting identity of said business; accessing 
the World Wide Web and retrieving and extracting information related to said detected identity; 
summarizing said extracted information, and performing a business transaction based on said 
summarized information. The present invention also provides an article of manufacture 
comprising a computer usable medium having computer readable program code embodied 
therein implementing the steps of this method. 
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In the Claims 



Independent claims 1,10, 14, 23, and 27 have been amended to correct minor informalities. No 
new matter has been added. 

REJECTIONS UNDER 35 U.S.C. 3 102 
Claims 1-4, 7-14, 18-23, and 27 are rejected under 35 U.S.C. § 102(e) as being 
anticipated by U.S. 6,708,202 (Shuman). 

Shuman appears to teach a form for displaying an electronic message item which includes 
an information object that highlights important information about the message. The information 
displayed in the information object is automatically derived by examining the message properties 
that constitute the message item. The examination of the message properties includes applying a 
series of if-then statements to predetermined message properties. If the results of one or more of 
the if-then tests are true, the program composes one or more information items that reflect the 
state of the message item. The program will also examine data external to the message item. The 
information items are composed in a natural language format and are prioritized prior to being 
displayed in the information object. 

The examiner has pointed to various figures and lines within Shuman to equate to various 
claim elements. It will be shown that many of these citations, upon closer inspection, do not 
correlate as suggested. A rejection under 35 U.S.C. § 102(e) requires that each and every 
element of the claims be shown in a single reference. Many elements in the claims will be shown 
to be missing from the Shuman and other applied references. 
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The examiner has pointed to figure 3 as illustrating the claimed element "receiving an 
incoming communication from a source intended for one or more recipients". However, figure 3 
appears limited to an illustration of client applications 300, client interfaces 315, service 
providers 325, and messaging systems 320. The examiner is requested to point to the element 
which illustrates the active step of receiving . Applicants believe no such illustration appears 
within the cited figure. Additionally, the examiner has pointed to figure 9, element 910 as 
showing the receiving feature. Element 910 is a step of receiving user input to select a message 
item to view. In other words, the user is simply selecting a message from a list. This does not 
equate to the element "receiving an incoming communication from a source intended for one or 
more recipients". 

Claim 1, section a, and equivalent sections in other claims provide "...incoming 
communications comprising a plurality of communication types..." (emphasis added). The 
Shuman reference is limited to an email application with no teaching of how one would modify 
the email system to work with a plurality of systems such as telephone, fax, IM, etc. While email 
is one communication medium noted in the claim, it is but one of a plurality of mediums. The 
use of multiple mediums is not contemplated by Shuman and therefore cannot anticipate the 
present invention, nor would it have been obvious to have modified Shuman. 

The examiner has pointed to figure 9 elements 915 and 920 and corresponding 
specification discussions as providing the identity of said source. A closer review of these 
elements shows that element 915 identifies form to use to display (not a source ID function) and 
element 920 examines message properties. While the message may contain a user's email 
address ("from" element), it does not automatically identify the source. It is typical for a person 
to create email addresses which do not reveal their identity. 
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The examiner has pointed to columns 11 and 16 of Shuman to suggest the "retrieving 
from a database data regarding said detected source and extracting data comprising any of, the 
following information. ..." However, a closer reading shows that Shuman is extracting the users 
calendar info, not the sources. Specifically, Shuman column 16, lines 44-47, "For example, if the 
message item is a meeting request, the computer must read external data associated with the 
user's calendar program. . . . (emphasis added). 

Section e of claim 1, and equivalent sections in other claims, cites "notifying said one or 
more recipients of said incoming communication". The examiner's citations to all steps a-d 
happen chronologically after the user has already selected a message item from a list (see figure 
9, element 910 Shuman and remaining flowchart) and therefore the user is "not" notified of an 
incoming communication after data extraction. In the presently claimed invention, steps a-d 
have already been performed on an email, telephone call, fax, IM, before the recipient is even 
notified. This feature enables the source information to be available instantly upon acceptance of 
the communication as opposed to initiating the process message by message as they are selected. 

With respect to claim 2, Shuman is silent on the claimed feature "past event entries". The 
examiner has only pointed to sections which describe conflicts with a new meeting request. 

With respect to claim 3, the examiner has pointed to Shuman elements 30, 34, and 320 as 
providing "sockets, JAVA messaging Queue (JMQ), remote procedure call (RPC) or remote 
method invocation (RMI)". The elements pointed to by the examiner are the interfaces and 
messaging system with no discussion of the claimed elements. 

With respect to claim 4, Shuman appears to indicate that their system could be 
implemented in various locations in a distributed computing environment. However, no explicit 
recitation of implementing the extracting step over a network is described. 
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With respect to claims 7, 11, 19, Shuman fails to provide an explicit recitation of a client 
profile database. 

With respect to claims 8 and 12, Shuman appears to indicate that their system could be 
implemented across the global internet. However, no explicit recitation of implementing the 
extracting step over said network is described. 

With respect to the rejections of claims 14, the above arguments apply as well as further 
reiterating that the database stores information of the source . Column 14, lines 17-19, explicitly 
cite storing data "only in the message" (line 16) and additionally "an appointment calendar 
maintained by the user " (lines 18-19; emphasis added). Additionally, the user (Shuman element 
910), not a retrieval manager, initiates retrieval of data. This provision enables a user to have all 
of the info they need automatically provided to them "before" they are notified of the incoming 
communication. 

With respect to claim 18, column 6 lines 30-50, do not cite a paper message, an email 
message, or a telephone call. They simply are directed to various modem connections methods, 
e.g. dial-up, cable, etc. 

With respect to claim 20, the present invention can be implemented on a multiplicity of 
devices. Shuman limits all discussions to a PC with various processors. 

With respect to claim 21, Shuman, in column 12, lines 45-55 only discusses checking the 
user's calendar and is silent on a database identifying specific calendar entry locators associated 
with said one or more sources . 

With respect to claim 22, Shuman does not provide a teaching of use over a wireless 
network. 
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With respect to the rejections of claims 23, 27, the above arguments apply as well as 
further reiterating that Shuman is limited to extraction of data within the message and about the 
user, but is silent as to extraction of external data about a business separate from the message 
itself. As such, no identification of the business is described and no specific business transaction 
is described. 

As shown above, Shuman fails to provide many of the claimed elements and therefore the 
present invention cannot be properly rejected under 35 U.S.C. § 102. In addition, Shuman fails 
to suggest many of the claimed features and therefore a rejection under 35 U.S.C. § 103 would 
also be deemed improper. The examiner is respectfully requested to remove the rejection. 

REJECTIONS UNDER 35 U.S.C. § 103 

Claims 5, 15, and 25 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. 6,708,202 (Shuman) as applied to claims 1, 10, and 23 above, and further in view of 
U.S. 2002/01 16505 (Higgins). 

Higgins appears to teach a content provider which interfaces a client with a server. The 
content provider includes a task manager operable to initiate and manage a session for a client 
and to query the server, when required, for content requested by the client. The content provider 
also includes session content storage for storing content associated with that session. The content 
provider further includes a protocol adapter operable to respond to the task manager for 
interfacing with the server to retrieve content requested by the client. The retrieved content is 
stored in the session content storage associated with the session for the client. 
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While Higgins does illustrate use of the iCalendar format and a web browser (well known 
items) for data retrieval, the combination of references does not provide this function for the 
source of an incoming communication. 

Claims 6 and 16 are rejected under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. 6,708,202 (Shuman) and U.S. 2002/01 16505 (Higgins) as applied to claims 1, 5, 10, and 15 
above, and further in view of U.S. 6,828,989 (Cortright). 

Cortright involves a system and process for graphically representing time dependent 
information or data objects, from at least one separate program, in a sequential manner using a 
dynamic time strip having implicit or explicit indications of time. In particular, the dynamic time 
strip is a linear graphical strip comprising graphical representations of time dependent 
information elements or data objects which may or may not include text or markers to indicate 
the time (i.e. second, minute, hour, day and/or date) along the length of the strip. As time passes, 
and data objects are changed, added or removed from the time strip, either automatically or 
through user interaction, the time strip is automatically and dynamically updated to reflect these 
changes along with showing the passage of time. The period of time represented by the dynamic 
time strip is preferably one day, with the dynamic time strip automatically scrolling forward as 
time passes. However, in one embodiment, the period of time represented by the dynamic time 
strip is user configurable. 

The examiner appears to have added Cortright to teach ordered appointment data. 
Cortright does appear to teach displaying time ordered data. However, Shuman compares the 
incoming message single request for an appointment with the recipient's calendar. No 
chronological listing of the "sources" data is even discussed in Shuman, nor is there a need for 
such, and therefore would not be provided by the combination of references. 
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Claim 17 is rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. 6,708,202 
(Shuman) as applied to claim 14 above, and further in view of U.S. 6,990,513 (Belfiore). 

Belfiore teaches a server federation cooperatively which interacts to fulfill service 
requests by communicating using data structures that follow a schema in which the meaning of 
the communicated data is implied by the schema. Thus, in addition to the data being 
communicated, the meaning of the data is also communication allowing for intelligent decisions 
and inferences to be made based on the meaning of the data. Cooperative interaction is facilitated 
over a wide variety of networks by messaging through a common API that supports multiple 
transport mechanisms. Also, mid-session transfer between client devices is facilitated by schema 
and the transport-independent messaging structure. The user interfaces of the client devices will 
appear consistent even if the client devices have different user interface capabilities. 

The examiner appears to have added Belfiore to teach use of SQL. Claim 17 is 
patentably distinct based on the limitations of the rejection as described above in the arguments 
with respect to claims 14 and 1. 

Claim 26 is rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. 6,708,202 
(Shuman) as applied to claim 23 above, and further in view of U.S. 6,347,307 (Sandhu). 

Sandu provides a system and method that enables users, such as institutional investors 
and financial institutions, to engage in capital market transactions, including the trading of Over- 
the-Counter financial products, via the Internet (including the World Wide Web). The system 
includes a variety of servers, applications, and interfaces that enable users to interactively 
communicate and trade financial instruments among one another, and to manage their portfolios. 
Interactive communications supported by the system include: requesting price quotes, monitoring 
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and reviewing quote requests, issuing price quotes, monitoring and reviewing price quotes, 
negotiation between users, acceptance of price quotes, reporting, portfolio management, analysis 
of financial information and market data, calendaring, and communications among users and/or 
system administrators, including e-mail, chat, and message boards. The present invention also 
supports communications with the server side in an automated manner via an automated 
processor. Such automated communications enable connectivity with users' internal, back-end 
systems to execute automated, straight-through processing, including transaction pricing, 
payment scheduling and journaling, derivatives trading, trade confirmation, and trade settlement. 
Such communications are facilitated using a novel XML-based syntax (FinXML(TM)) and XSL- 
based processing language (FinScript(TM)). FinXML provides a standard data interchange 
language for capital market transactions and supports a broad set of elements and attributes that 
represent a wide variety of financial transactions, reference data, and market data. The common 
description of the FinXML syntax can be used for all aspects of straight-through-processing, 
including deal creation, confirmation, settlement, payment, risk management, and accounting. 

The examiner appears to have added Sandhu et al. to teach calendaring in a financial 
service environment. Claim 26 is patentably distinct based on the limitations of the rejection as 
described above in the arguments with respect to claims 23, 14 and 1. 

SUMMARY 

As has been detailed above, none of the references, cited or applied, provide for the 
specific claimed details of applicants' presently claimed invention, nor renders them obvious. It 
is believed that this case is in condition for allowance and reconsideration thereof and early 
issuance is respectfully requested. 
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This response is being filed with a request for extension of time. The Commissioner is 
hereby authorized to charge the extension fee, as well as any deficiencies in the fees provided to 
Deposit Account No. 12-0010. 

If it is felt that an interview would expedite prosecution of this application, please do not 
hesitate to contact applicants' representative at the below number. 

Respectfully submitted, 

Randy W. Lacasse 
Registration No. 34,368 

1725 Duke Street 
Suite 650 

Alexandria, Virginia 22314 
(703) 838-7683 

September 13, 2006 
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